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In  this  paper  we  describe  a  formalism  for  integrating  the  SHOP  HTN  planning  sys¬ 
tem  with  the  IMPACT  multi-agent  environment.  We  define  the  A-SHOP  algorithm, 
an  agentized  adaptation  of  the  SHOP  planning  algorithm  that  takes  advantage  of 
IMPACT’S  capabilities  for  interacting  with  external  agents,  performing  mixed  sym¬ 
bolic/numeric  computations,  and  making  queries  to  distributed,  heterogeneous  in¬ 
formation  sources  (such  as  arbitrary  legacy  and/or  specialized  data  structures  or 
external  databases).  We  show  that  A-SHOP  is  both  sound  and  complete  if  certain 
conditions  are  met. 

Keywords:  multi-agent  systems,  HTN  planning,  heterogenous/distributed  data, 
AMS  Subject  classification:  Primary  68T20;  Secondary  68T30 


1.  Introduction 

In  order  to  apply  AI  planning  systems  to  complex  real-world  planning  problems, 
here  are  some  of  the  challenges  that  must  be  addressed: 

1.  The  need  for  the  planning  system  to  interact  with  external  information  sources 
[CHWE95].  This  problem  tends  to  be  complicated  by  the  fact  that  the  in¬ 
formation  sources  are  frequently  heterogeneous  and  not  necessarily  central¬ 
ized.  For  example,  in  an  information  integration  project  developed  for  the 
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US  Army,  the  information  sources  included  a  US  Army  route  planner  over 
free  terrain  [BS94],  a  variety  of  US  Army  logistics  data  including  special¬ 
ized  Oracle  and  nested  multi-record  TAADS  data  [SRM98],  a  variety  of  US 
Army  simulation  data  from  a  massive  program  called  JANUS,  Training  and 
Instrumentation  Command,  a  face  recognition  program,  and  so  forth. 

2.  The  need  to  perform  mixed  symbolic/numeric  reasoning.  For  example, 
[NSE98]  describes  the  need  to  reason  about  a  variety  of  numeric  and  symbolic 
conditions  in  order  to  do  manufacturing  planning  and  to  plan  declarer  play 
in  the  game  of  bridge. 

3.  The  need  to  coordinate  multiple  agents.  For  example,  in  planning  the  move¬ 
ment  of  a  cargo  container  from  its  point  of  origin  to  its  ultimate  destination, 
a  number  of  agents  might  participate  in  the  control  of  the  container:  agents 
that  load  ships,  higher  level  managers  that  react  to  unusual  incidents,  and 
so  forth.  The  container  agent  would  need  to  take  these  into  account  in  plan 
development.1 

Although  a  variety  of  approaches  have  been  proposed  for  several  of  these 
challenges,  none  of  them  has  yet  been  completely  solved — and  no  current  theory 
of  planning  addresses  all  of  these  challenges  simultaneously. 

The  formalism  described  in  this  paper  is  intended  to  address  all  of  the  above 
challenges  simultaneously,  by  integrating  the  SHOP  planning  system  with  the 
IMPACT  multi-agent  environment.  While  SHOP  [NCLMA99]  is  a  very  efficient 
stand-alone  HTN  planner,  the  multi-agent  platform  IMPACT  [SBD+00,ESP99] 
provides  facilities  for  interacting  with  heterogeneous,  distributed  information 
sources  (including  arbitrary  legacy  and/or  specialized  data  structures  or  exter¬ 
nal  databases),  combining  symbolic  and  numerical  information,  and  coordinating 
multiple  agents.  In  this  paper,  we  define  A-SHOP  (an  agentized  version  of  SHOP), 
and  show  how  to  realize  it  as  an  IMPACT  agent  (see  Figure  2  in  Section  3).  This 
makes  it  possible  for  other  IMPACT  agents  to  communicate  with  A-SHOP  and  let 
it  solve  their  own  planning  problems. 

Although  we  have  developed  our  formalism  only  for  SHOP,  we  believe  that 
a  similar  approach  could  be  used  to  integrate  other  AI  planners  into  I M  PACT  as 
well.  The  main  new  results  in  this  paper  are  as  follows: 

1  In  this  paper,  we  only  consider  the  case  where  the  other  agents  are  information  sources  (rather 
than  other  planning  agents).  We  intend  to  address  the  coordination  of  multiple  planning 
agents  in  our  future  work. 
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•  the  definition  of  the  A-SHOP  planning  algorithm,  an  agentized  version  of 
SHOP  that  runs  in  the  IMPACT  environment; 

•  the  formulation  of  the  conditions  needed  for  A-SHOP  to  be  sound  and  com¬ 
plete; 

•  proofs  that  A-SHOP  is  sound  and  complete  if  those  conditions  are  met. 

In  addition,  we  are  working  on  an  implementation  of  our  formalism,  for  an  appli¬ 
cation  domain  involving  military  logistics  planning  (work  currently  in  progress). 
This  is  an  example  of  a  domain  where  the  SHOP- IMPACT  framework  can  be 
very  useful:  information  about  the  different  assets  is  not  centralized;  and  the  in¬ 
formation  sources  are  heterogeneous,  comprising  different  database  management 
systems  (DBMS). 

This  paper  is  organized  as  follows.  In  Section  2  we  review  HTN  planning, 
the  planning  approach  that  SHOP  is  based  on.  In  Section  3  we  briefly  introduce 
IMPACT,  a  platform  for  agents  collaborating  together.  Section  4  contains  the 
definition  of  A-SHOP  (Figure  2  illustrates  how  to  turn  A-SHOP  into  a  planning 
agent  shop  within  IMPACT).  Section  5  contains  our  main  theorems,  which  estab¬ 
lish  the  soundness  and  completeness  of  A-SHOP  with  respect  to  certain  conditions 
on  the  code  calls — conditions  that  were  already  well  studied  in  IMPACT.  Finally, 
we  discuss  related  work  in  Section  7  and  conclude  with  Section  8.  The  appendix 
contains  detailed  definitions  of  those  concepts  that  could  not  be  covered  in  the 
main  part  of  the  paper. 


2.  HTN  Planning  in  SHOP 

HTN  planning  [Sac77,Tat77,Wil88,CT91]  is  an  AI  planning  methodology  that 
creates  plans  by  task  decomposition.  This  is  a  process  in  which  the  planning 
system  decomposes  tasks  into  smaller  and  smaller  subtasks,  until  primitive  tasks 
are  found  that  can  be  performed  directly. 

SHOP  (see  <http://www.cs.umd.edu/projects/shop/>  and  [NCLMA99, 
NMAC+01])  is  a  domain-independent  Hierarchical  Task  Network  (HTN)  planning 
algorithm.  However,  one  difference  between  SHOP  and  most  other  HTN  planning 
algorithms  is  that  SHOP  plans  for  tasks  in  the  same  order  that  they  will  later 
be  executed.  Planning  for  tasks  in  the  order  that  those  tasks  will  be  performed 
makes  it  possible  to  know  the  current  state  of  the  world  at  each  step  in  the 
planning  process,  which  makes  it  possible  for  SHOP’S  precondition-evaluation 
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mechanism  to  incorporate  significant  inferencing  and  reasoning  power,  including 
the  ability  to  call  external  programs  to  reason  about  preconditions.  This  makes 
SHOP  ideal  as  a  basis  for  integrating  planning  with  external  information  sources, 
such  as  the  IMPACT  framework  as  described  in  this  paper. 

In  order  to  do  planning  in  a  given  planning  domain,  SHOP  needs  to  be  given 
knowledge  about  that  domain.  SHOP’S  knowledge  base  contains  operators  and 
methods.  Each  operator  is  a  description  of  what  needs  to  be  done  to  accomplish 
some  primitive  task,  and  each  method  is  a  prescription  for  how  to  decompose 
some  complex  task  into  a  totally  ordered  sequence  of  subtasks,  along  with  various 
restrictions  that  must  be  satisfied  in  order  for  the  method  to  be  applicable.  More 
than  one  method  may  be  applicable  to  the  same  task,  in  which  case  there  will  be 
more  than  one  possible  way  to  decompose  that  task. 

Given  the  next  task  to  accomplish,  SHOP  chooses  an  applicable  method, 
instantiates  it  to  decompose  the  task  into  subtasks,  and  then  chooses  and  instan¬ 
tiates  other  methods  to  decompose  the  subtasks  even  further.  If  the  constraints 
on  the  subtasks  prevent  the  plan  from  being  feasible,  SHOP  will  backtrack  and 
try  other  methods. 

As  an  example,  Figure  1  shows  two  methods  for  the  task  of  traveling  from 
one  location  to  another:  travelling  by  air,  and  travelling  by  taxi.  Travelling  by  air 
involves  the  subtasks  of  purchasing  a  plane  ticket,  travelling  to  the  local  airport, 
flying  to  an  airport  close  to  our  destination,  and  travelling  from  there  to  our 
destination.  Travelling  by  taxi  involves  the  subtasks  of  calling  a  taxi,  riding  in  it 
to  the  final  destination,  and  paying  the  driver. 

Note  that  each  method’s  preconditions  are  not  used  to  create  subgoals  (as 
would  be  done  in  action-based  planning).  Rather,  they  are  used  to  determine 
whether  or  not  the  method  is  applicable.  For  example,  in  Figure  1,  the  travel-by- 
air  method  is  only  applicable  for  long  distances,  and  the  travel-by-taxi  method 
is  only  applicable  for  short  distances. 

Now,  consider  the  task  of  travelling  from  the  University  of  Maryland  to 
MIT.  Since  this  is  a  long  distance,  the  travel-by-taxi  method  is  not  applicable, 
so  we  must  choose  the  travel-by-air  method.  As  shown  in  Figure  1,  this  decom¬ 
poses  the  task  into  the  following  subtasks:  (1)  purchase  a  ticket  from  Baltimore- 
Washington  International  (BWI)  airport  to  Logan  airport,  (2)  travel  from  the 
University  of  Maryland  to  BWI,  (3)  fly  from  BWI  airport  to  Logan  airport,  and 
(4)  travel  from  Logan  airport  to  MIT.  For  the  subtasks  of  travelling  from  the 
University  of  Maryland  to  BWI  and  traveling  from  Logan  to  MIT,  we  can  use 
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buy-ticket(a(x),a(y)) 

travel(x,a(x)) 

fly(a(x),a(y)) 

travel(a(y))y) 

^travel  (UMD,  MIT) 


'  subtasks 


buy-ticket(B  WI, Logan) 
travel  (UMD,  B  WI) 


get-taxi 

ride-taxi(UMD,BWI) 
pay-driver 


fly(BWI,  Logan) 
travel  (Logan,  MIT) 


get-taxi 

ride-taxi(Logan,MIT) 
pay-driver _ 


Figure  1.  Two  methods  for  traveling,  and  a  plan  generated  from  those  methods. 

the  travel-by-taxi  method  to  produce  additional  subtasks  as  shown  in  Figure  1. 

Here  are  some  of  the  complications  that  can  arise  during  the  planning  pro¬ 
cess: 

•  The  planner  may  need  to  recognize  and  resolve  interactions  among  the  sub¬ 
tasks.  For  example,  in  planning  how  to  travel  to  the  airport,  we  might  want 
to  make  sure  we  will  arrive  at  the  airport  in  time  to  catch  the  plane.  To  make 
the  example  in  Figure  1  more  realistic,  the  information  needed  to  enforce  this 
constraint  could  be  specified  as  part  of  SHOP’S  methods  and  operators. 

•  In  the  example  in  Figure  1,  it  was  always  obvious  which  method  to  use.  But 
in  general,  more  than  one  method  may  be  applicable  to  a  task.  If  it  is  not 
possible  to  solve  the  subtasks  produced  by  one  method,  SHOP  will  backtrack 
and  try  another  method  instead. 


3.  IMPACT 

The  IMPACT  project  (see  [ESP99,SBD+00]  and  http://www.cs.umd.edu/ 
projects/impact/)  aims  at  developing  a  powerful  and  flexible,  yet  easy  to  han¬ 
dle  framework  for  the  interoperability  of  distributed  heterogeneous  sources  of 
information.  The  following  points  are  of  special  interest  for  our  integration  of 
SHOP  with  IMPACT: 

•  IMPACT’S  methodology  for  transforming  arbitrary  software  (legacy  code)  into 
an  agent  has  been  developed. 

•  Each  agent  has  certain  actions  available.  Agents  act  in  their  environment 
according  to  their  agent  program  and  a  well  defined  semantics. 

•  IMPACT  Agents  are  built  on  top  of  arbitrary  software  code  ( Legacy  Data). 

•  Each  agent  continually  undergoes  the  following  cycle: 
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bxnA  Singlfexn agent 


IMPACT  Architecture 


Figure  2.  (1)  SHOP  as  a  planning  agent  in  IMPACT.  (2)  An  Agent  in  IMPACT. 

(1)  Get  messages  by  other  agents.  This  changes  the  state  of  the  agent. 

(2)  Determine  (based  on  its  program,  its  semantics  and  its  state)  for  each 
action  its  status  (permitted,  obliged,  forbidden,  . . . ).  The  agent  ends  up 
with  a  set  of  status  atoms. 

(3)  Based  on  a  notion  of  concurrency,  determine  the  actions  that  can  be  exe¬ 
cuted  and  update  the  state  accordingly. 

A  complete  description  of  all  these  notions  is  out  of  scope  of  this  paper,  but  the 
appendix  contains  some  formal  definitions.  In  the  following,  we  concentrate  only 
on  those  notions  that  are  essential  to  understand  the  integration  of  SHOP  in 
IMPACT. 

Before  explaining  an  agent  in  detail,  we  need  to  make  some  comments  about 
the  general  architecture.  In  IMPACT  agents  communicate  with  other  agents 
through  the  network.  Not  only  can  they  send  out  (and  receive)  messages  from 
other  agents,  they  can  also  ask  the  server  to  find  out  about  services  that  other 
agents  offer.  For  example  a  planning  agent  (like  shop),  confronted  with  a  par¬ 
ticular  planning  problem,  can  find  out  if  there  are  agents  out  there  with  the 
data  needed  to  solve  the  planning  problem;  or  agents  can  provide  shop  with 
information  about  relevant  legacy  data. 

One  of  the  main  features  of  IMPACT  is  to  provide  a  method  (see  [SBD+00]) 
for  agentizing  arbitrary  legacy  code,  i.e.  to  turn  such  legacy  code  into  an  agent. 
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In  order  to  do  this,  we  need  to  abstract  from  the  given  code  and  describe  its  main 
features.  Such  an  abstraction  is  given  by  the  set  of  all  datatypes  and  functions 
the  software  is  managing.  We  call  this  a  body  of  software  code  and  denote  it  by 
S  =  ( Xs,tFs )■  J~S  is  a  set  of  predefined  functions  which  makes  access  to  the  data 
objects  managed  by  the  agent  available  to  external  processes. 

For  example,  in  many  applications  a  statistics  agent  is  needed.  This  agent 
keeps  track  of  distances  between  two  given  points  and  the  authorized  range  or  ca¬ 
pacity  of  certain  vehicules.  These  information  can  be  stored  in  several  databases. 
Another  example  is  the  supplier  agent.  It  determines  through  its  databases 
which  vehicles  are  accessible  at  a  given  location. 

At  any  given  point  t  in  time,  the  state  of  an  agent ,  denoted  Os(t),  is  the  set 
of  all  data  objects  that  are  currently  stored  in  the  relations  the  agent  handles — 
the  types  of  these  objects  must  be  in  the  base  set  of  types  in  Ts-  In  the  two 
examples  just  mentioned,  the  state  of  the  statistics  agent  consists  of  all  tuples 
stored  in  the  databases  it  handles.  The  state  of  the  supplier  agent  is  the  set  of 
all  tuples  describing  which  vehicles  are  accessible  at  a  given  location. 

We  also  assume  that  agents  can  send  and  receive  messages.  There  is  there¬ 
fore  a  special  datastructure,  the  message  box ,  part  of  each  agent.  This  message 
box  is  just  one  of  those  types.  Thus  a  state  change  occurs  already  when  a  message 
is  received.  A  state,  O,  can  be  seen  as  the  union  of  the  states  of  all  agents  in  the 
environment. 

To  perform  logical  reasoning  on  top  of  third  party  data  structures  (which 
are  part  of  the  agent’s  state)  and  code,  the  agent  must  have  a  language  within 
which  it  can  reason  about  the  agent  state.  We  therefore  introduce  the  concept 
of  a  code  call  atom,  which  is  the  basic  syntactic  object  used  to  access  multiple 
heterogeneous  data  sources. 


Definition  1  (Code  Calls  (cc)).  Suppose  S  =def  (Tsi^s)  is  some  software 
code,  /  £  is  a  predefined  function  with  n  arguments,  and  di,...,dn  are 
objects  or  variables  such  that  each  di  respects  the  type  requirements  of  the  i’th 
argument  of  /.  Then,  S  :/( di, . . .  ,  dn)  is  a  code  call.  A  code  call  is  ground  if  all 
the  di’s  are  objects. 

We  often  identify  software  code  S  with  the  agent  that  is  built  on  top  of  it. 
This  is  because  an  agent  really  is  uniquely  determined  by  it. 
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A  code  call  executes  an  API  function  and  returns  as  output  a  set  of  objects 
of  the  appropriate  output  type.  Going  back  to  our  two  agents  introduced  above, 
statistics  may  be  able  to  execute  the  code  calls  statistics  :  distance^ locFrom,  locTo), 
statistics  :  author  Range  (CargoPL),  and  statistics  :  author  Capacity  (CargoPL).  The 
supplier  agent  may  execute  the  following  code  call:  supplier :  cargoPlane (locFrom). 

What  we  really  need  to  know  is  if  the  result  of  evaluating  such  code  calls  is 
contained  in  a  certain  set  or  not  (for  a  precise  description  of  the  results  of  the 
code  calls  just  mentioned  we  refer  to  Section  C  in  the  Appendix).  To  do  this, 
we  introduce  code  call  atoms.  These  are  logical  atoms  that  are  layered  on  top  of 
code  calls.  They  are  defined  through  the  following  inductive  definition. 

Definition  2  (Code  Call  Atoms  (in(X,  cc) ) ) .  If  cc  is  a  code  call,  and  X  is 
either  a  variable  symbol,  or  an  object  of  the  output  type  of  cc,  then  in(X,  cc) 
and  not_in(X,  cc)  are  code  call  atoms,  not  Jn(X,  cc)  succeeds  if  X  is  not  in  the 
set  of  objects  returned  by  the  code  call  cc. 

Code  call  atoms,  when  evaluated,  return  boolean  values,  and  thus  may  be  thought 
of  as  special  types  of  logical  atoms.  Intuitively,  a  code  call  atom  of  the  form 
in(X,  cc)  succeeds  if  X  can  be  set  to  a  pointer  to  one  of  the  objects  in  the  set  of 
objects  returned  by  executing  the  code  call. 

As  an  example,  the  code  call  atom  in(/22,  supplier  :  cargoPlane (collegepark)) 
tells  us  that  the  particular  plane  “/22”  is  available  as  a  cargo  plane  in  College 
Park. 

Often,  the  results  of  evaluating  code  calls  give  us  back  certain  values  that 
we  can  compare.  Based  on  such  comparisons,  certain  actions  might  be  fired  or 
not.  To  this  end,  we  need  to  define  code  call  conditions.  Intuitively,  a  code 
call  condition  is  a  conjunction  of  code  call  atoms,  equalities,  and  inequalities. 
Equalities,  and  inequalities  can  be  seen  as  additional  syntax  that  “links”  together 
variables  occurring  in  the  atomic  code  calls. 

The  following  definition  expresses  this  intuition. 

Definition  3  (Code  Call  Conditions  (ccc)).  A  code  call  condition  x  is  de¬ 
fined  as  follows: 

1.  Every  code  call  atom  is  a  code  call  condition. 

2.  If  s,t  are  either  variables  or  objects,  then  s  =  t  is  a  code  call  condition. 
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3.  If  s,t  are  either  integer/real  valued  objects,  or  are  variables  over  the  inte¬ 
gers/reals,  then  s<t,s>t,s>t,s<t  are  code  call  conditions. 

4.  If  xi>X2  are  code  call  conditions,  then  xi  &X2  is  a  code  call  condition. 

A  code  call  condition  satisfying  any  of  the  first  three  criteria  above  is  an  atomic 
code  call  condition. 

We  are  now  coming  to  the  very  heart  of  the  definition  of  an  agent:  its  agent 
program.  Such  a  program  consists  of  rules  of  the  form: 

Opa(fi, . . .  ,tm) «-  Op!/?i(. ..),...,  Op „/?„(. . .), 

CCC\  , ,  cccr , 

where  a,  (3\, . . .  f3n  are  actions  (the  agent  can  execute),  0p1, ....  0p„  describe  the 
status  of  the  action  ( obliged ,  forbidden,  waived,  doable)  and  ccci  are  code  call 
conditions  to  be  evaluated  in  the  actual  state. 

Thus,  Op,  are  operators  that  take  actions  as  arguments.  They  describe  the 
status  of  the  arguments  they  take.  Here  are  some  examples  of  actions:  (1)  to 
load  some  cargo  from  a  certain  location,  (2)  to  fly  a  plane  from  a  certain  location 
to  another  location,  (3)  to  unload  some  cargo  from  a  certain  location.  The  action 
status  atom  F  load  (resp.  Do  fly)  means  that  the  action  load  is  forbidden  (resp. 
fly  should  be  done).  Actions  themselves  are  terms,  only  with  an  operator  in  front 
of  them  they  become  atoms. 

In  IMPACT,  actions  are  very  much  like  STRIPS  operators:  they  have  pre¬ 
conditions  and  add  and  delete-lists  (see  appendix).  The  difference  to  STRIPS  is 
that  these  preconditions  and  lists  consist  of  arbitrary  code  call  conditions,  not 
just  of  logical  atoms. 

If  we  compare  IMPACT  actions  with  SHOP’s  methods,  we  easily  notice  that 
IMPACT  actions  correspond  to  fully  instantiated  methods,  i.e.  no  subtasks. 

Figure  2  illustrates  that  the  agent  program  together  with  the  chosen  se¬ 
mantics  SEM  and  the  state  of  the  agent  determines  the  set  of  all  status  atoms. 
However,  the  doable  actions  among  them  might  be  conflicting  and  therefore  we 
have  to  use  the  chosen  concurrrency  notion  to  finally  determine  which  actions  can 
be  concurrently  executed.  The  agent  then  executes  these  actions  and  changes  its 
state. 

The  IMPACT  framework  has  been  extended  to  incorporate  time  ([DKS01]), 
probabilities  ([DNSOO]),  beliefs  ([DSPOO]),  and  also  mechanisms  to  merge  many 
code  calls  together  so  that  they  can  be  more  efficiently  executed  ([DOSOO]). 
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4.  A-SHOP:  The  IMPACT  Version  of  SHOP 

To  plan  with  external  information  sources,  A-SHOP’s  domain  representation  in¬ 
cludes  explicit  calls  to  the  IMPACT  agents  to  enquire  about  their  current  states 
and  to  modify  their  states  as  we  will  explain  now. 

4.1.  A-SHOP ’s  Domain  Definitions 

The  first  step  is  to  modify  the  atoms  in  SHOP’s  preconditions  and  effects,  so  that 
SHOP’S  preconditions  will  be  evaluated  by  IMPACT’S  code  call  mechanism  and 
the  effects  will  change  the  state  of  the  IMPACT  agents.  This  is  a  fundamental 
change  in  the  representation  of  SHOP.  In  particular,  it  requires  replacing  SHOP’s 
methods  and  operators  with  agentized  methods  and  operators.  These  are  defined 
below. 

Definition  4  (Agentized  Method:  (AgentMeth  h\  t)).  An  agentized 
method  is  an  expression  of  the  form  (AgentMeth  hx t)  where  h  (the  method’s 
head)  is  a  compound  task,  x  (the  method’s  preconditions)  is  a  code  call  condition 
and  t  is  a  totally  ordered  list  of  subtasks,  called  the  task  list. 

The  primary  difference  between  definition  of  an  agentized  method  and  the 
definition  of  a  method  in  SHOP  is  as  follows.  In  SHOP,  preconditions  were  logical 
atoms,  and  SHOP  would  infer  these  preconditions  from  its  current  state  of  the 
world  using  Horn-clause  inference.  In  contrast,  the  preconditions  in  an  agentized 
method  are  IMPACT’S  code  call  conditions  rather  than  logical  atoms,  and  A-SHOP 
(the  agentized  version  of  SHOP  defined  in  the  next  section)  does  not  use  Horn- 
clause  inference  to  establish  these  preconditions  but  instead  simply  invokes  those 
code  calls,  which  are  calls  to  other  agents  (which  may  be  Horn-clause  theorem 
provers  or  may  instead  be  something  entirely  different). 

Definition  5  (Agentized  Operator:  (AgentOp  hxaddXdei ))•  An  agentized 
operator  is  an  expression  of  the  form  (AgentOp  hxadd  Xdei),  where  h  (the  head) 
is  a  primitive  task  and  Xadd  and  Xdei  are  lists  of  code  calls  (called  the  add-  and 
delete-lists) .  The  set  of  variables  in  the  tasks  in  Xadd  and  Xdei  is  a  subset  of  the 
set  of  variables  in  h. 

As  an  example,  Figure  3  shows  a  method  for  our  application  to  military 
logistics  planning.  The  method  indicates  how  to  transport  a  cargo  that  has  a 
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certain  weight  between  two  locations.  The  method  calls  the  statistics  agent 
three  times,  in  order  to  evaluate  the  distance  between  two  geographic  locations, 
the  authorized  range  of  a  certain  aircraft  type  (the  authorized  range  is  lower 
than  the  real  distance  that  the  aircraft  can  fly),  and  the  authorized  capacity  of 
an  aircraft  (the  amount  of  weight  the  aircraft  can  carry).  The  method  calls  the 
supplier  agent  to  evaluate  the  cargo  planes  that  are  available  at  a  location. 


Head: 

Air  Transport  (LocFrom,  LocTo,  Cargo,  CargoWeiglit) 

Preconditions: 

in(CargoPL,  supplier  :  cargoPlane (locFrom))& 
in(Dist,  statistics  :  distance (locFrom,  locTo))& 
in(DCargoPL,  statistics :  awf/iorRange(CargoPL))& 
Dist  <  DCargoPLfe 

in(CCargoPL,  statistics  :  author  Capacity  (CargoPL))& 
CargoWeight  <  CCargoPL& 

Subtasks: 
load( Cargo,  locFrom) 
fly( Cargo,  locFrom,  LocTo) 
unload( Cargo,  locTo) 


Figure  3.  Agentized  method  for  a  military  logistics  problem. 


The  primary  difference  between  the  definition  of  an  agentized  operator  and 
the  definition  of  an  operator  in  SHOP  is  that  in  an  agentized  operator,  the  el¬ 
ements  of  the  add  list  and  delete  list  are  lists  of  code  call  rather  than  atoms. 
As  described  in  the  next  section  this  has  several  consequences  for  how  A-SHOP 
reasons  about  its  current  state  of  the  world. 

4-2.  The  A-SHOP  Algorithm 

The  second  step  of  the  integration  is  to  modify  SHOP’s  HTN  planning  al¬ 
gorithm  to  use  IMPACT.  The  modified  algorithm,  which  we  call  the  A-SHOP 
algorithm,  is  shown  in  Figure  4.  Given  a  list  t  of  tasks  to  achieve,  and  a  collec¬ 
tion  T>  of  agentized  methods  and  operators,  A-SHOP  looks  at  the  first  task  in  the 
list.  If  that  task  is  primitive  (Step  3),  then  A-SHOP  looks  for  a  simple  plan  con- 
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procedure  A-SHOP(t,T>) 

1.  if  t  =  nil  then  return  nil 

2.  t  :=  the  first  task  in  t;  R  :=  the  remaining  tasks 

3.  if  t  is  primitive  and  a  simple  plan  for  t  exists  then 

4.  q  :=  simplePlanit) 

5.  return  concatenate^,  A-SHOP(i?.,  V)) 

6.  else  if  t  is  non-prim.  A  there  is  a  reduction  of  t,  then 

7.  nondeterministically  choose  a  reduction: 

Nondeterministically  choose  an  agentized  method, 

(AgentMeth  h\t),  with  p  the  most  general 

unifier  of  h  and  t  and  substitution  6  s.t. 

XpO  is  ground  and  holds  in  IMPACT’S  state  O. 

8.  return  A-SH0P(concatenate(t,p,9 ,  R) ,V) 

9.  else  return  FAIL 

10.  end  if 
end  A-SHOP 

procedure  simplePlan(t) 

11.  nondeterministically  choose  agent,  operator 
op  =  (AgentOp  hxaddXdei)  with  v  the  most 
general  unifier  of  h  and  t  s.t.  h  is  ground 

12.  monitoring  :  apply  (op  u) 

13.  return  opv 
end  A-SHOP 

Figure  4.  A-SHOP,  the  agentized  version  of  SHOP. 

sisting  of  a  single  operator  (Step  4),  and  then  calls  itself  recursively  to  examine 
the  remaining  tasks  (Step  5),  the  function  concatenate  simply  concatenates  the 
plan  q  with  the  next  plan  that  is  obtained  by  the  recursive  call).  If  the  task  is 
compound  and  reducible  (step  6),  then  A-SHOP  applies  an  agentized  method  to 
produce  subtasks  (steps  7-8). 

Unlike  SHOP  (which  would  apply  an  operator  by  directly  inserting  and 
deleting  atoms  from  an  internally-maintained  state  of  the  world),  A-SHOP  needs 
to  reason  about  how  the  code  calls  in  an  operator  will  affect  the  states  of  other 
agents.  One  might  think  the  simplest  way  to  do  this  would  be  simply  to  tell  these 
agents  to  execute  the  code  calls  and  then  observe  the  results,  but  this  would  not 
work  correctly.  Once  the  planning  process  has  ended  successfully,  A-SHOP  will 
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return  a  plan  whose  operators  can  be  applied  to  modify  the  states  of  the  other 
IMPACT  agents — but  A-SHOP  should  not  change  the  states  of  those  agents  during 
its  planning  process  because  this  would  prevent  A-SHOP  from  backtracking  and 
trying  other  operators. 

Thus  in  Step  12,  SHOP  does  not  issue  code  calls  to  the  other  agents  directly, 
but  instead  communicates  them  to  a  monitoring  agent.  The  monitoring  agent 
keeps  track  of  all  operators  that  are  supposed  to  be  applied,  without  actually 
modifying  the  states  of  the  other  IMPACT  agents.  When  A-SHOP  queries  for  a 
code  call  cc  =  S  :/( di, ....  dn)  in  \  t°  evaluate  a  method’s  precondition  (Step  7), 
the  monitoring  agent  examines  if  cc  has  been  affected  by  the  intended  modifica¬ 
tions  of  the  operators  and,  if  so,  it  evaluates  cc.  If  cc  is  not  affected  by  application 
of  operations,  IMPACT  evaluates  cc  (i.e.,  by  accessing  S).  The  list  of  operators 
maintained  by  the  monitoring  agent  is  reset  everytime  a  planning  process  begins. 
The  apply  function  applies  the  operators  and  creates  copies  of  the  state  of  the 
world.  Depending  on  the  underlying  software  code,  these  changes  might  be  easily 
revertible  or  not.  In  the  latter  case,  the  monitoring  agent  has  to  keep  track  of 
the  old  state  of  the  world. 

Like  the  original  SHOP  algorithm  [NCLMA99],  A-SHOP  performs  ordered 
task  decomposition.  This  means  that  the  task  list  t  is  totally  ordered,  the  tasks 
need  to  be  achieved  in  that  same  order,  and  SHOP  always  plans  for  the  tasks 
in  that  same  order.  Like  SHOP,  A-SHOP  needs  to  create  partial  plans,  reason 
about  the  intermediate  states  of  those  partial  plans,  those  partial  plans  might 
do,  and  backtrack  if  necessary  to  construct  other  partial  plans.  In  SHOP,  all 
of  this  is  done  inside  the  planning  algorithm.  However  A-SHOP  cannot  do  all 
of  it  internally  because  of  the  necessity  of  communicating  with  other  agents  to 
get  information  about  the  current  state.  In  general,  A-SHOP's  preconditions  will 
contain  code  calls  to  other  agents,  and  the  operators  in  its  plans  will  contain 
code  calls  to  other  agents.  Since  A-SHOP  may  need  to  backtrack,  it  needs  to 
reason  about  what  the  consequences  will  be  of  those  code  calls  without  actually 
telling  the  other  agents  to  execute  those  code  calls.  To  accomplish  this,  A-SHOP 
simulates  calling  the  other  agents  by  sending  those  code  calls  to  a  monitoring 
agent,  monitoring  (Steps  7  and  12). 

This  is  the  key  point  of  the  integration  of  SHOP  in  the  IMPACT  multi-agent 
environment:  AI  planners  traditionally  evaluate  preconditions  in  a  state,  assumed 
to  be  internal  to  the  planner.  This  assumption  may  be  infeasible  in  many  real- 
world  situations.  In  A-SHOP,  instead,  the  preconditions  are  evaluated  externally 
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by  IMPACT  agents. 


Tl,  . .  . , Tn 

IMPACT 


Tl, . . . , Tn 


Figure  5.  Data  flow  in  (a)  SHOP  and  (b)  A-SHOP. 


4-3.  Realizing  shop 

The  third  step  is  to  create  an  IMPACT  agent,  called  shop,  that  acts  as  a 
planning  agent  and  performs  the  A-SHOP  algorithm.  To  accomplish  this,  we  can 
use  the  general-purpose  agentizing  algorithm  described  in  [SBD+00].  This  enables 
A-SHOP  to  communicate  with  other  IMPACT  agents  and  vice-versa.  Basically, 
the  agentizing  algorithm  outputs  a  protocol  that  presents  the  procedure  calls  of 
the  software  in  a  standardized  format  that  allows  other  agents  to  communicate 
with  it.  For  the  particular  situation  of  a  planning  system,  the  protocol  includes 
a  call  to  a  procedure  that  receives  as  input  a  problem  description  and  outputs  a 
solution  plan  (please  refer  to  [SBD+00]  for  a  detailed  discussion  of  the  algorithm). 


5.  Soundness  and  Completeness 

An  important  question  for  any  planning  algorithm  is  whether  all  solution  plans 
produced  by  the  algorithm  are  correct  (i.e.,  soundness  of  the  algorithm)  and 
whether  the  algorithm  will  find  solutions  for  solvable  problems  (i.e.,  complete¬ 
ness  of  the  algorithm).  Soundness  and  completeness  proofs  of  classical  planners 
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assume  that  the  preconditions  can  be  evaluated  relative  to  the  current  state.  In 
SHOP,  for  example,  the  state  is  accessed  to  test  whether  a  method  is  applicable, 
by  examining  whether  the  method’s  preconditions  are  valid  in  the  current  state. 
Normally  it  is  easy  to  guarantee  the  ability  to  evaluate  preconditions,  because  the 
states  typically  are  lists  of  predicates  that  are  locally  accessible  to  the  planner. 
However,  if  these  lists  of  predicates  are  replaced  by  code  call  conditions,  this  is 
no  longer  the  case. 

Code  call  conditions  are  statements  in  a  logical  language  referring  to  arbi¬ 
trary  software  functions.  As  an  example,  we  consider  a  software  package  math 
which  provides  several  functions  to  deal  with  integers.  The  code  call  math :  geq(X) 
enumerates  all  integers  greater  or  equal  to  X.  This  cc  is  not  executable,  because  it 
is  not  ground.  Only  if  the  variable  X  is  assigned  a  certain  value,  the  code  call  can 
be  executed.  A  syntactical  condition  to  ensure  this  is  safeness  (see  appendix). 
But  safeness  is  not  enough!  Consider  the  code  call 

in(X,  math :  geq{ 25))  & 

in(Y,  math :  square(X ))  &  Y  <  2000, 

which  constitutes  all  numbers  that  are  less  than  2000  and  that  are  squares  of  an 
integer  greater  than  or  equal  to  25. 

Clearly,  over  the  integers  there  are  only  finitely  many  ground  substitutions 
that  cause  this  code  call  condition  to  be  true.  Furthermore,  this  code  call  condi¬ 
tion  is  safe.  However,  its  evaluation  may  never  terminate.  The  reason  for  this  is 
that  safety  requires  that  we  first  compute  the  set  of  all  integers  that  are  greater 
than  25,  leading  to  an  infinite  computation. 

Thus  in  general,  we  must  impose  some  restrictions  on  code  call  conditions 
to  ensure  that  they  are  finitely  evaluable.  This  is  precisely  what  the  condition 
of  strongly  safeness  does  for  the  code-call  conditions.  Intuitively,  by  requiring 
that  the  code  call  condition  is  safe,  we  are  ensuring  that  it  is  executable  and  by 
requiring  that  it  is  strongly  safe,  we  are  ensuring  that  it  will  only  return  finitely 
many  answers. 

Note  that  the  problem  of  deciding  whether  an  arbitrary  code  call  execution 
terminates  is  undecidable  (and  so  is  the  problem  of  deciding  whether  a  code  call 
condition  x  holds  in  O).  Therefore  we  need  some  input  of  the  agent  designer 
(or  of  the  person  who  is  responsible  for  the  legacy  code  the  agent  is  built  upon). 
The  information  needed  is  stored  in  a  finiteness  table  (see  Definition  13).  This 
information  is  used  in  the  purely  syntactic  notion  of  strong  safeness.  It  is  a 
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compile-time  check ,  an  extension  of  the  well-known  (syntactic)  safety  condition 
in  databases. 

Lemma  6  (Evaluating  Agentized  Operators). 

Let  O  be  a  state,  ( AgentMeth  h  x  t)  an  agentized  method  and  ( AgentOp  h'  Xadd  Xdei) 
an  agentized  operator.  If  the  precondition  x  is  strongly  safe  wrt.  the  variables  in 
h,  the  problem  of  deciding  whether  x  holds  in  O  can  be  algorithmically  solved. 

If  the  add  and  delete-lists  Xadd  and  Xdei  are  strongly  safe  wrt.  the  variables  in 
h' ,  the  problem  of  applying  the  agentized  operator  to  O  can  be  algorithmically 
solved. 

Proof:  This  follows  immediately  from  results  in  Chapter  12  of  [SBD+00].  | 


Theorem  1  (Soundness,  Completeness). 

Let  O  be  a  state  and  T>  be  a  collection  of  agentized  methods  and  operators.  If 
all  the  preconditions  in  the  agentized  methods  and  add  and  delete-lists  in  the 
agentized  operators  are  strongly  safe  wrt.  the  respective  variables  in  the  heads, 
then  A-SHOP  is  correct  and  complete. 

Proof:  See  Appendix  E.  | 


6.  Implementation 

A  version  of  IMPACT  is  running  on  a  Windows  platform.  This  version  has  been 
built  primarily  in  JAVA.  The  implementation  of  IMPACT  uses  a  pre-existing  soft¬ 
ware  package  developed  at  the  University  of  Maryland  called  WebHermes  [Ada97] 
which  supports  execution  of  code  call  conditions  over  a  wide  variety  of  data 
structures  and  software  packages.  These  currently  include  (or  have  included 
in  the  past),  relational  database  management  systems  (Oracle,  Ingres,  Dbase, 
Paradox),  an  object  oriented  system  (ObjectStore),  a  multimedia  system  called 
MACS  [BMS95],  a  video  information  system  called  AVIS  [ACC+96],  a  geographic 
data  structure  called  a  PR-quadtree,  arbitrary  flat  files  (as  long  as  their  schemas 
are  specified),  a  US  Army  route  planner  over  free  terrain  [BS94],  a  variety  of  US 
Army  logistics  data  including  specialized  Oracle  and  nested  multirecord  TAADS 
data  [SRM98],  a  variety  of  US  Army  simulation  data  from  a  massive  program 
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called  JANUS  deployed  by  the  Simulation,  Training  and  Instrumentation  Com¬ 
mand,  a  face  recognition  program,  and  so  on. 

The  complete  version  of  SHOP  is  built  in  LISP  and  includes  the  abil¬ 
ities  to  do  Horn-clause  inferencing  and  to  make  calls  to  the  LISP  evalua¬ 
tor.  The  former  one  is  used  to  infer  conditions  from  the  current  state  and 
the  latter  one  is  used  to  add  expressiveness  during  planning.  For  example, 
SHOP  can  compute  numerical  expressions.  SHOP  can  be  downloaded  from 
<http://www.cs.umd.edu/projects/shop/>.  To  facilitate  the  integration  of 
SHOP  in  IMPACT,  we  re-implemented  SHOP  in  java.  The  java  version  of  SHOP 
includes  neither  the  Horn  clause  evaluator  nor  the  calls  to  the  LISP  evaluator. 
However,  such  things  could  easily  be  added  through  the  use  of  the  IMPACT  frame¬ 
work,  without  needing  any  modifications  to  the  current  JAVA  implementation  of 
SHOP.  In  particular,  we  could  take  an  arbitrary  theorem  prover  and  agentize  it 
using  IMPACT  methods.  The  agent  could  then  be  called  using  an  appropriate 
code-call  condition  ([SBD+OO]  describes  a  step  by  step  process  to  agentize  a  pro¬ 
gram  and  incorporate  it  as  an  agent  into  IMPACT).  The  same  can  be  done  for 
evaluations.  In  particular,  a  mathematical  agent,  math.,  is  currently  available  in 
IMPACT  to  evaluate  some  numerical  expressions. 

A  difficulty  that  we  found  in  implementing  the  A-SHOP  algorithm  is  that 
rules  defining  agents  in  IMPACT  are  not  recursive  over  time:  they  do  not 
formalize  statements  of  the  form  If  some  code  calls  are  executed  at  time  t  then 
some  other  facts  hold  true  at  time  t  +  1.  In  fact,  the  basic  framework  of  IMPACT 
does  not  even  express  statements  of  the  form  If  something  is  true  at  time  t  then 
something  else  should  be  true  at  time  t  +  1.  Such  an  extension  is  described 
in  [DKS01]. 

In  our  version  of  IMPACT,  the  status  set  is  computed  for  a  particular  point 
in  time  t.  Thus  while  agent  rules  are  recursive,  they  always  determine  a  status 
set  for  a  single  time  point.  This  status  set  together  with  a  particular  evaluation 
strategy  determines  the  set  of  actions  to  be  executed.  Agent  rules  do  not  describe 
the  effects  of  these  actions. 

This  made  it  necessary  to  define  four  agents  to  implement  the  A-SHOP 
algorithm: 

•  Ashop.  This  is  the  agent  that  all  other  agents  access  to  generate  a  plan. 
It  receives  a  message  with  a  domain  and  a  list  of  tasks  and  returns  a  plan 
achieving  all  tasks  if  such  a  plan  exists  or  returns  failure  if  no  such  plan  exists. 
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Figure  6.  Interactions  between  the  agents  implementing  the  A-SHOP  algorithm. 

•  ReduceTask.  Selects  the  next  task  to  be  reduced  and  performs  a  single  reduc¬ 
tion  step  by  selecting  either  a  method  or  an  operator. 

•  CCCondition.  Evaluates  a  code  call  condition  (i.e. ,  a  list  of  code  calls). 

•  Monitoring.  Maintains  a  list  of  actions  to  be  executed.  If  a  code  call 
S  :/(di, . . . ,  dn)  is  to  be  evaluated,  it  looks  at  its  action  list  to  determine 
if  the  code  call  can  be  answered  as  a  result  of  its  actions.  If  not  it  queries  the 
code  call  to  the  information  source  S. 

Figure  6  describes  how  these  four  agents  interact.  First,  a  message  request¬ 
ing  a  plan  is  (1)  received  by  the  Aslxop  agent.  This  message  contains  a  domain, 
T>.  and  a  list  of  tasks,  t,  to  be  achieved.  Ashop  initializes  some  variables  and 
(2)  passes  them  to  ReduceTask  together  with  t  and  V.  If  the  first  task,  t,  in  t 
is  compound,  it  selects  a  method  whose  head  matches  t  and  (3)  passes  its  pre¬ 
conditions  to  CCCondition.  CCCondition  iterates  over  the  preconditions  (4) 
passing  one  by  one  to  Monitoring  for  evaluation.  If  t  is  primitive,  it  selects 
an  operator  whose  head  matches  t  and  (5)  passes  the  instantiated  operator  to 
Monitoring  to  update  its  action  list. 

Steps  (1)  and  (2)  are  executed  once  in  every  planning  episode.  Step  (3)  is 
executed  for  each  selected  method.  Step  (4)  is  executed  for  every  code  call  in  the 
method’s  preconditions  and  Step  (5)  is  executed  for  each  selected  operator. 

We  plan  to  conduct  experiments  in  a  simplified  version  of  planning  for  Non- 
combatant  evacuation  operations  (IVEO’s).  NEO' s  are  are  conducted  to  assist 
the  U.S.A.  Department  of  State  (DoS)  with  evacuating  noncombatants,  nonessen¬ 
tial  military  personnel,  selected  host-nation  citizens,  and  third  country  nationals 
whose  lives  are  in  danger  from  locations  in  a  host  foreign  nation  to  an  appro¬ 
priate  safe  haven.  They  usually  involve  the  swift  insertion  of  a  force,  temporary 
occupation  of  an  objective  (e.g.,  an  embassy),  and  a  planned  withdrawal  after 
mission  completion.  NEO's  are  often  planned  and  executed  by  a  Joint  Task  Force 
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(JTF),  a  hierarchical  multi-service  military  organization,  and  conducted  under  an 
American  Ambassador’s  authority.  Force  sizes  can  range  into  the  hundreds  and 
involve  all  branches  of  the  armed  services,  while  the  evacuees  can  number  into  the 
thousands.  More  than  ten  iVEO’s  were  conducted  within  the  past  decade.  Pub¬ 
lications  describe  NEO  doctrine,  case  studies  [Sie91],  and  more  general  analyses 
(e.g.,  [S.92]). 

In  our  experiments  we  use  a  knowledge  base  that  we  developed  for  NEO 
planning.  Its  plans  concern  performing  a  rescue  mission  where  troops  are  grouped 
and  transported  between  an  initial  location  (the  assembly  point)  and  the  NEO 
site  (where  the  evacuees  are  located).  Once  the  troops  arrive  to  the  NEO  site, 
evacuees  are  re-located  in  a  safe  haven.  Planning  involves  selecting  possible  pre¬ 
defined  routes,  consisting  of  four  segments  each.  The  planner  must  also  choose 
means  of  transportation  for  each  segment.  The  knowledge  base  included  six  agen- 
tized  operators  and  22  agentized  methods.  There  are  five  information  sources, 
one  for  each  location,  which  include  the  assembly  point  and  the  NEO  site.  The 
other  locations  are:  the  ISB  (intermediate  staging  base,  where  the  troops  are  or¬ 
ganized  previous  to  accessing  the  NEO  site) ,  the  FAARP  (where  logistics  equip¬ 
ment  is  grouped)  and  the  Safe  Haven  (where  the  evacuees  are  re-located  once 
the  operation  ends).  These  information  sources  contain  information  about  the 
corresponding  locations,  including:  (1)  which  assets  are  available,  (2)  what  are 
the  meterological  conditions  and  (3)  information  about  enemy  presence  in  that 
area. 

Different  agentized  methods  are  triggered  depending  on  the  particular  in¬ 
formation  maintained  in  an  specific  location.  For  example,  selecting  an  agentized 
method  taking  the  air  transport  to  re-locate  the  evacuees  between  the  NEO  Site 
and  the  Safe  Haven  requires  that  (1)  the  NEO  Site  and  the  Safe  Haven  have  air¬ 
ports,  (2)  that  sufficinet  airplanes  are  available  at  the  NEO  Site  and  (3)  that  the 
methereological  conditions  in  the  NEO  Site  and  the  Safe  Haven  are  appropriate. 
Each  of  these  requirements  is  expressed  in  several  code  calls,  in  which  each  of  the 
information  sources  is  queried  to  establish  if  the  requirements  are  met. 

7.  Related  Work 

Most  AI  planning  systems  are  unable  to  evaluate  numeric  conditions  at  all.  A  few 
can  evaluate  numeric  conditions  using  attached  procedures  (e.g.,  SI  PE  [Wil88], 
0-Plan  [CT91],  TLplan  [BKOO]  and  SHOP  [NCLMA99]),  but  the  lack  of  a  formal 
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semantics  for  these  attached  procedures  makes  it  more  difficult  to  guarantee 
soundness  and  completeness.  Integer  Programming  (IP)  models  appear  to  have 
excellent  potential  as  a  uniform  formalism  for  reasoning  about  complex  numeric 
and  symbolic  constraints  during  planning,  and  some  work  is  already  being  done 
on  the  use  of  IP  for  reasoning  about  resources  [Koh98,KW99,WW99].  However, 
that  work  is  still  work  in  progress,  and  a  number  of  fundamental  problems  still 
remain  to  be  solved. 

Approaches  for  planning  with  external  information  sources  typically  have  in 
common  that  the  information  extracted  from  the  external  information  sources  is 
introduced  in  the  planning  system  through  built-in  predicates  [EWD+92,GEW94, 
Kno96,FW97].  For  example,  a  modified  version  of  UCPOP  uses  information  gath¬ 
ering  goals  to  extract  information  from  the  external  information  sources  [Kno96] . 
The  information  gathering  goals  are  used  as  preconditions  of  the  operators.  The 
primary  difficulty  with  this  approach  is  that  since  it  is  not  clear  what  the  seman¬ 
tic  of  the  built-in  predicates  is,  this  makes  it  difficult  to  guarantee  soundness  and 
completeness. 

Distributed  problem-solving  (eg.  [DS83])  has  been  the  focus  of  research  for 
many  years.  With  the  advances  in  agent  research  [WJ95],  attention  has  been 
driven  towards  the  coordination  of  the  decision  making  process  between  multiple 
agents.  However,  much  work  is  still  needed  in  developing  well-founded  reasoning 
and  negotiating  techniques,  in  particular  in  environments  in  which  the  agent  must 
constantly  be  on  the  lookout  for  changes  (see  [dDJW99]  for  a  recent  survey).  An 
interesting  approach  is  the  RETSINA  project  [PKP+00,PSS00].  In  RETSINA  each 
agent  can  do  its  own  planning,  as  each  agent  is  equipped  with  a  special  planning 
component  in  its  internal  architecture.  In  contrast  to  this,  we  have  chosen  that 
one  special  planning  agent,  shop,  does  the  planning  upon  request  from  other 
agents. 

PL  AC  A  (PLAnning  Communicating  Agents)  is  an  agent-oriented  language 
[Tho93,Tho94],  PLACA  adds  two  mechanisms  to  the  agent’s  state  :  (consistent) 
list  of  intentions  and  a  list  of  (consistent)  plans.  Intentions  are  adopted  via 
commands  expressed  in  the  PLACA  language.  Plans  are  created  by  an  external 
plan  generator  to  meet  these  intentions.  In  A-SHOP  the  intensions  are  indicated 
in  the  tasks  to  be  achieved  and  the  A-SHOP  planning  algorithm  perform  a  task 
decomposition  process  that  results  in  the  plans  achieving  those  tasks  (i.e. ,  meeting 
the  intentions). 

AgentSpeak(L)  [Rao96]  is  a  Believe-Desire-Intention  (BDI)  language  and,  like 
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PLACA,  capable  of  expressing  beliefs,  commitments  and  communications  between 
agents.  However,  AgentSpeak(L)  provides  operational  and  proof-theoretic  seman¬ 
tics  and  does  not  provide  any  planning  features.  In  this  paper  we  demonstrated 
A-SHOP’s  operational  semantics  by  showing  that  it  is  sound  and  complete. 

3APL  ([HBdHM99])  is  a  general  agent  programming  language  the  opera¬ 
tional  semantics  of  which  is  based  on  transition  systems.  It  inherits  quite  a  lot  of 
regular  programming  constructs  from  imperative  programming,  such  as  recursive 
procedures  but  is  built  upon  clear  formal  semantics.  As  a  very  general  agent 
programming  language,  it  is  much  more  general  than  IMPACT’S  agent  programs. 
However,  there  is  no  specialized  planning  component  available.  Certainly,  plan¬ 
ning  algorithms  might  be  implemented  in  this  language,  but  there  is  no  particular 
support  for  that.  It  has  been  shown  that  various  languages  such  as  AgentSpeak(L) 
or  ConGolog  can  be  easily  embedded  in  3APL. 

8.  Conclusion 

We  have  developed  A-SHOP,  a  modified  version  of  the  SHOP  planning  algorithm 
that  takes  advantage  of  the  capabilities  provided  by  the  IMPACT  multi-agent  envi¬ 
ronment.  A-SHOP  can  plan  with  heterogeneous,  distributed  information  sources, 
combine  symbolic  and  numerical  information,  and  interact  with  multiple  agents. 

In  the  A-SHOP  algorithm,  SHOP’S  preconditions,  add-lists  and  delete-lists 
are  replaced  with  code  call  conditions.  IMPACT’S  code  call  conditions  provide 
both  well-defined  syntax  and  a  well-defined  semantics.  This  has  enabled  us  to 
show  that  A-SHOP  is  sound  and  complete  provided  that  the  code  calls  are  strongly 
safe. 

Using  the  methodology  outlined  in  [SBD+00],  it  is  straightforward  to  turn 
A-SHOP  into  a  planning  agent  shop. 

A-SHOP,  like  most  AI  planners,  normally  constructs  entire  plans  before 
beginning  plan  execution.  In  a  multi-agent  setting,  it  would  be  desirable  to  have 
the  ability  to  interleave  planning  with  plan  execution.  In  the  current  A-SHOP 
algorithm,  this  could  be  accomplished  by  giving  A-SHOP  a  set  of  methods  and 
operators  that  tell  it  to  produce  a  high-level  plan  {pi, . . .  ,pk)  in  which  each  pi  is 
itself  a  call  to  A-SHOP.  However,  since  this  approach  is  somewhat  ad  hoc ,  one  of 
our  topics  for  future  work  is  to  develop  an  extension  to  the  A-SHOP  formalism 
that  explicitly  interleaves  planning  with  plan  execution. 

Note  that  unlike  most  AI  planning  algorithms,  A-SHOP  does  not  have  any 
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information  about  its  state  stored  locally.  However,  we  could  if  needed  simulate 
having  a  local  state  by  simply  defining  an  agent  that  manages  the  state  and  hav¬ 
ing  all  code  call  conditions  refer  to  that  agentized  state.  Intermediate  approaches 
such  as  Knob  lock’s  [Kno96],  which  updates  the  current  state  by  gathering  infor¬ 
mation  from  external  sources,  can  also  be  subsumed  in  our  integration:  again  we 
could  have  an  specialized  agent  managing  the  partial  state  of  the  world. 

A-SHOP’s  use  of  IMPACT’S  code  call  atoms  allows  us  to  address  the  chal¬ 
lenges  stated  in  the  introduction: 

•  Mixed  symbolic/numeric  reasoning.  Notice  that  the  precondition  of  the 
method  shown  in  Figure  3  supposes  a  combination  symbolic  and  numeric  rea¬ 
soning.  On  one  hand,  this  method  is  used  as  a  means  for  decomposing  the 
task 


Air  Transport  (LocFrom,  LocTo,  Cargo,  CargoWeight), 

which  is  essentially  a  symbolic  process.  On  the  other  hand,  some  of  its  precon¬ 
ditions  are  numerical  comparisons  (i.e. ,  Dist  <  DCargoPL).  This  is  a  simple 
illustration  of  a  greater  potential:  by  decoupling  the  evaluation  of  precondi¬ 
tions  from  the  planning  process  itself  we  are  gaining  flexibility.  Specialized 
agents  performing  complex  numerical  calculations  can  be  plugged  in. 

•  Distributed,  heterogeneous  information  sources.  One  important  effect 
of  integrating  A-SHOP  within  IMPACT  is  that  it  allows  A-SHOP  to  gather 
information  from  distributed,  heterogeneous  information  sources  without  re¬ 
quiring  knowledge  about  how  and  where  these  resources  are  located.  For 
example,  in  the  method  shown  in  Figure  3,  determining  the  statistics  of  a  cer¬ 
tain  airplane  might  simply  require  access  to  a  local  database,  but  determining 
if  any  such  airplanes  are  available  in  a  certain  location  might  require  access  to 
a  remotely  located  spreadsheet. 

It  is  interesting  to  note  that  according  to  a  recent  study,  handling  resources 
separately  from  the  planning  process  can  improve  the  performance  of  planning 
systems  [SK99] .  We  have  not  yet  examined  whether  such  an  improvement 
occurs  in  A-SHOP  (as  opposed  to  SHOP),  but  we  hope  to  be  able  to  examine 
it  in  the  future. 

•  Coordination  of  multiple  agents.  Every  time  A-SHOP  does  a  code  call, 
a  request  to  contact  an  external  agent  is  made.  The  IMPACT  multi-agent 
environment  coordinates  this  process.  In  principle,  this  could  be  used  not  only 
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to  communicate  between  A-SHOP  and  the  other  agents,  but  also  to  coordinate 
multiple  versions  of  A-SHOP  itself.  We  have  not  yet  implemented  multiple 
copies  of  A-SHOP  running  concurrently,  but  we  hope  to  do  so  in  the  near 
future. 
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Appendix 

A.  IMPACT 

The  following  definition  specifies  what  a  solution  of  a  code  call  condition  is. 
Intuitively,  code  call  conditions  are  evaluated  against  an  agent  state — if  the  state 
of  the  agent  changes,  the  solution  to  a  code  call  condition  may  also  undergo  a 
change. 
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Definition  7  (Code  Call  Solution).  Suppose  x  is  a  code  call  condition  in¬ 
volving  the  variables  X  =def  {Xi, . . . , Xn},  and  suppose  S  =def  (Xs-XsXs)  is 
some  software  code.  A  solution  of  x  w.r.t.  7s  in  a  state  Os  is  a  legal  assignment 
of  objects  oi, on  to  the  variables  X\, ... ,  Xn,  written  as  a  compound  equation 
X  :=  o,  such  that  the  application  of  the  assignment  makes  x  true  in  state  Os- 
We  denote  by  SoI(x)t5,o5  (omitting  subscripts  Os  and  Ts  when  clear  from 
the  context),  the  set  of  all  solutions  of  the  code  call  condition  x  in  state  Os, 
and  by  C_SoI(x)t5,o5  (where  subscripts  are  occasionally  omitted)  the  set  of  all 
objects  appearing  in  SoI(x)ts,o5 

Here  is  the  notion  of  an  action  as  used  in  IMPACT. 

Definition  8  (Action;  Action  Atom).  An  action  a  consists  of  six  compo¬ 
nents: 

Name:  A  name,  usually  written  a(Xi, . . .  ,  Xn),  where  the  Xj’s  are  root  variables. 
Schema:  A  schema,  usually  written  as  (n,...,rn),  of  types.  Intuitively,  this 
says  that  the  variable  Xj  must  be  of  type  ly,  for  all  1  <  i  <  n. 

Action  Code:  This  is  a  body  of  code  that  executes  the  action. 

Pre:  A  code-call  condition  called  the  precondition  of  the  action,  denoted  by 
Pre(a)  (Pre(a)  must  be  safe  modulo  the  variables  X\,. . .  ,Xn)\ 

Add:  a  set  Add(a)  of  code-call  conditions; 

Del:  a  set  Del(a)  of  code-call  conditions. 

We  close  with  the  definition  of  action  atom.  An  action  atom  is  a  formula 
a(t\, . . .  ,tn),  where  t{  is  a  term,  i.e. ,  an  object  or  a  variable,  of  type  r*,  for  all 
i  =  1, . . . ,  n. 

What  is  the  difference  with  this  approach  and  the  classical  AI  framework? 


Item 

Classical  AI 

Our  framework 

State  O 

Set  of  logical  atoms 

Data  structures 

Prec 

Logical  formula 

Code  call  condition 

Add/Del 

set  of  ground  atoms 

Code  call  condition 

Irnpl. 

Via  add/delete  lists 

Via  arbitrary  code 

Reas. 

Via  add/del  lists 

Via  add/del  lists 

States  in  classical  AI  planning  are  physically  modified  by  union-ing  the  cur¬ 
rent  state  with  items  in  the  add  list,  and  then  deleting  items  in  the  delete  list. 
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In  contrast,  the  add-list  and  the  delete- list  in  our  framework  plays  no  role  what¬ 
soever  in  the  physical  implementation  of  the  action.  The  action  is  implemented 
by  its  associated  action  code.  The  agent  uses  the  preconditions,  add  list,  and  the 
delete  list  to  reason  about  what  is  true/false  in  the  new  state. 

Definition  9  (Status  Atom/Status  Set).  If  a(f)  is  an  action,  and  Op  e 
{P,  F,  W,  Do  ,  O},  then  OpQ'(t)  is  called  a  status  atom.  If  A  is  a  status  atom, 
then  A ,  ->A  are  called  status  literals.  A  status  set  is  a  finite  set  of  ground  status 
atoms. 

Intuitively,  Pa  means  a  is  permitted,  Fa  means  a  is  forbidden,  Do  a  means  a 
is  actually  done,  Oa  means  a  is  obliged,  and  Wa  means  that  the  obligation  to 
perform  a  is  waived. 

Definition  10  (Agent  Program). An  agent  program  V  is  a  finite  set  of  rules 
of  the  form 

A  <—  x  &  L\  &  . . .  &  Ln 

where  x  is  a  code  call  condition  and  Li,,...,Ln  are  status  literals. 

The  semantics  of  agent  programs  are  described  in  [ESP99,ES99,SBD+00]. 

B.  Termination  of  Code  Calls 

Note  that  the  following  definitions  underlying  strongly  safeness  are  important  for 
the  general  case,  when  an  agent  is  built  upon  arbitrary  code.  For  most  appli¬ 
cations,  like  our  military  logistics  domain,  the  safety  requirement  is  completely 
sufficient. 

As  already  mentioned,  strongly  safeness  is  a  condition  to  ensure  that  code 
calls  are  not  only  evaluable,  but  that  they  generate  only  finitely  many  answers 
(they  eventually  terminate)  [ESROO].  Now  given  an  arbitrary  function,  the  prob¬ 
lem  of  deciding  whether  its  range  is  finite  or  not  is  well-known  to  be  undecidable. 
Therefore  we  need  help  from  the  system  designer.  The  key  notion  is  the  following. 

Definition  11  (Binding  Pattern).  Suppose  we  consider  a  code  call  S  :  /(a*, . . . , 
where  each  is  of  type  t%.  A  binding  pattern  for  S :/( ai, ....  an)  is  an  n-tuple 
(bti, . . . ,  btn)  where  each  bti  (called  a  binding  term )  is  either: 


28 


Dix,  Munoz-Avila,  Nau,  Zhang  /  IMPACTing  SHOP 


1.  A  value  of  type  T{,  or 

2.  The  expression  b  denoting  that  this  argument  is  bound  to  an  unknown  value. 

We  require  that  the  agent  developer  must  specify  a  finiteness  predicate  that  may 
be  defined  via  a  finiteness  table  having  two  columns — the  first  column  is  the  name 
of  the  code  call,  while  the  second  column  is  a  binding  pattern  for  the  function  in 
question.  Intuitively,  suppose  we  have  a  row  of  the  form 

{S :/( a1,a2,a3),(b,5,b)) 

in  the  finiteness  table.  Then  this  row  says  that  the  answer  returned  by  any  code 
call  of  the  form  S:f(— ,5,  — )  is  finite.  In  other  words,  as  long  as  the  second 
argument  of  this  code  call  is  5,  the  answer  returned  is  finite,  irrespective  of  the 
values  of  the  first  and  third  arguments.  Clearly,  the  same  code  call  may  occur 
many  times  in  a  finiteness  table  with  different  binding  patterns. 

Definition  12  (Ordering  on  Binding  Patterns).  We  say  a  binding  pat¬ 
tern  (bti, . . . ,  btn)  is  equally  or  less  informative  than  another  binding  pattern 
(bt\ , . . . ,  bt'n)  if,  by  definition,  for  all  1  <  i  <  n,  bti  <  bt[. 

We  will  say  (bt\, . . .  ,btn)  is  less  informative  than  (bl\ . .  bl'u)  if  and  only 
if  it  is  equally  or  less  informative  than  (bt[, ,  bt'n)  and  (bt\, ... ,  bt'n)  is  not 
equally  or  less  informative  than  (bti,  •  •  • ,  btn).  If  (bt\ , . . . ,  bt'n)  is  less  informative 
than  (bti,  ■  ■  ■ ,  btn ),  then  we  will  say  that  (bti,  •  •  • ,  btn )  is  more  informative  than 
(bt'1,...,bt'n). 

Suppose  now  that  the  developer  of  an  agent  specifies  a  finiteness  table 
FINTAB.  The  following  definition  specifies  what  it  means  for  a  specific  code 
call  atom  to  be  considered  finite  w.r.t.  FINTAB. 

Definition  13  (Finiteness).  Suppose  FINTAB  is  a  finite  finiteness  table  ,  and 
(bti,  •  •  • ,  btn)  is  a  binding  pattern  associated  with  the  code  call  S  :/(•  •  •).  Then 
FINTAB  is  said  to  entail  the  finiteness  of  S:f( bti, . . .  ,btn)  if,  by  definition, 
there  exists  an  entry  of  the  form  (S  :/(. . .),  (bt\ , . . .  ,bt'n))  in  FINTAB  such  that 
(bti,  •  •  • ,  btn)  is  more  informative  than  (bt\ , . . . ,  bt'n). 

Definition  14  (Strong  Safety).  A  safe  code  call  condition  x  =  Xi  &  ■  ■  -  &Xn 
is  strongly  safe  w.r.t.  a  list  X  of  root  variables  if,  by  definition,  there  is  a 
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permutation  n  witnessing  the  safety  of  x  modulo  X  such  that  for  each  1  <  i  <  n, 
Xn (i)  is  strongly  safe  modulo  X,  where  strong  safety  of  Xn(i)  is  defined  as  follows: 

1.  XttU)  is  a  code  call  atom. 

Here,  let  the  code  call  of  Xn(i)  be  S  . . . ,  tn)  and  let  the  binding  pattern 

S  :/( bti, . . . ,  btn)  be  defined  as  follows: 

(a)  If  ti  is  a  value,  then  bti  =  t{. 

(b)  Otherwise  ti  must  be  a  variable  whose  root  occurs  either  in  X  or  in  Xn(j) 
for  some  j  <  i.  In  this  case,  bti  =  b. 

Then,  Xn(i)  is  strongly  safe  if,  by  definition,  FINTAB  entails  the  finiteness  of 
S  :/(bti, . . .  ,btn). 

2-  Xt> ■(»)  is  s  /  t. 

In  this  case,  Xn{i)  is  strongly  safe  if  by  definition,  each  of  s  and  t  is  either 
a  constant  or  a  variable  whose  root  occurs  either  in  X  or  in  Xn(j)  f°r  some 
j  <  i. 

3-  Xn(i)  is  s  <  t  or  s  <  t. 

In  this  case,  Xn(i)  is  strongly  safe  if,  by  definition,  t  is  either  a  constant  or  a 
variable  whose  root  occurs  either  in  X  or  somewhere  in  Xn(j)  f°r  some  j  <  i. 

4-  XttH)  is  s  >  t  or  s  >  t. 

In  this  case,  Xn(i)  is  strongly  safe  if,  by  definition,  t  <  s  or  t  <  s,  respectively, 
are  strongly  safe. 

Algorithms  to  check  strong  safety  are  developed  in  [SBD+00]. 

C.  Example  of  an  Application  Domain 

Military  logistics  planning  is  an  example  of  a  domain  where  the  S  FI  OP- IMPACT 
framework  can  be  very  useful.  In  particular  with  respect  to  logistics  planning 
for  the  US  Armed  Forces:  first,  information  about  the  different  assets  is  not  cen¬ 
tralized,  second,  the  information  sources  are  heterogeneous,  comprising  different 
database  management  systems  (DBMS). 

Figure  7  shows  some  of  the  code-calls  for  this  application.  The  first  three 
code-calls  access  the  agent  statistics  and  return  the  distance  between  two  ge¬ 
ographic  locations,  the  authorized  range  of  a  certain  aircraft  type  (the  autho¬ 
rized  range  is  lower  than  the  real  distance  that  the  aircraft  can  fly),  and  the 


30 


Dix,  Munoz-Avila,  Nau,  Zhang  /  IMPACTing  SHOP 


authorized  capability  (in  metric  tunes)  of  an  aircraft.  The  last  code-call  accesses 
the  agent  supplier  and  returns  the  cargo  planes  that  are  available  at  a  location. 


statistics  :  distance{ loci,  loc2) 
statistics :  authorRange{a.i.rcrait) 
statistics :  author  Capacity  (air  cr  aft) 
supplier:  cargo  Plane  (loc) 

Figure  7.  Code-calls  in  the  military  logistics  domain. 


Figure  3  illustrates  a  simple  agentized  method  which  mounts  a  cargo  in 
an  airplane  provided  that  the  airplane  has  the  adequate  range  and  capacity.  Al¬ 
though  simple,  the  capability  to  access  remote  information,  reason  on  the  different 
numbers  provides  prompt  and  accurate  information  and  may  decide  between  the 
success  and  failure  of  an  operation. 


D.  Planning 

In  what  follows,  a  state  denotes  the  union  of  the  states  of  all  IMPACT  agents. 
Definition  15  (Application  of  agentized  operator). 

Let  an  agentized  operator  op  =  (AgentOp  hxaddXdei )  be  given.  Applying  op  to 
a  state  O.  denoted  by  result ((9,  op),  results  in  a  new  state  O'  in  which: 

•  for  each  code  call  S  :/( di, . . .  ,  dn)  in  Xadd >  f{di,  •  •  • ,  dn)  is  added  to  the  state 
of  5; 

•  for  each  code  call  S  :f( d1; . . . ,  dn)  in  XdeU  f{di,  ■  •  • ,  dn)  is  removed  from  the 
state  of  S. 

Notice  that  during  the  planning  process  of  the  A-SHOP  algorithm,  operators  are 
not  applied  in  the  sense  of  the  previous  definition.  Instead,  the  monitoring 
agent  keeps  track  of  all  operators  that  are  supposed  to  be  applied,  without  ac¬ 
tually  modifying  the  state  of  the  IMPACT  agents.  When  A-SHOP  queries  for  a 
code  call  cc  =  S  :/(dl5 . . . ,  dn)  in  Xadd  to  evaluate  a  method’s  precondition,  the 
monitoring  agent  examines  if  cc  has  been  affected  by  the  intended  modifications 
of  the  operators  and,  if  so,  it  evaluates  cc.  If  cc  is  not  affected  by  application  of 
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operations,  IMPACT  evaluates  cc  (i.e.,  by  accessing  S).  If  the  planning  process 
ends  successfully,  the  operators  are  applied  as  indicated  in  the  previous  definition. 

Definition  16  (Plans)  .A  plan  is  a  list  of  heads  of  ground  agentized  operator 
instances.  If  P  =  {p\P2  ■  ■  ■  Pn )  is  a  plan  and  O  is  a  state,  then  the  result  of  applying 
P  to  O  is  the  state  result(0,  P)  =  result  (result  (. . .  (result(C>,pi),p2),  •  •  • ),Pn )• 

Definition  17  (Simple  reductions)  .Let  t  be  a  task,  O  be  a  state,  and  m  = 
(AgentMeth  /i%t)  be  an  agentized  method.  Suppose  that  u  is  a  unifier  for  h 
and  t,  and  that  v  is  a  unifier  that  unifies  each  atom  in  \u  with  some  atom  in  O. 
Then  the  agentized  method  instance  ( mu)v  is  applicable  to  t  in  O,  and  the  result 
of  applying  it  to  t  is  the  task  list  r  =  (t“)T  The  task  list  r  is  a  simple  reduction 
of  t  by  m  in  O. 

Definition  18  (Domains  and  problems). 

A  domain  representation  is  a  set  of  agentized  operators  and  methods.  A  planning 
problem  is  a  triple  (O,  t,V),  where  O  is  a  state,  t=  (tit-2 ---tk)  is  a  task  list, 
and  T>  is  a  domain  representation.  Suppose  (O,  t,P)  is  a  planning  problem  and 
P  =  (pip-2  ■  ■  ■ Pn )  is  a  plan.  Then  we  say  that  P  solves  (O,  t,V),  or  equivalently, 
that  P  achieves  t  from  O  in  T>  (we  will  omit  the  phrase  “in  T>"  if  the  identity  of 
T>  is  obvious)  if  any  of  the  following  is  true: 

Case  1:  t  and  P  are  both  empty,  (i.e.,  k  =  0  and  n  =  0); 

Case  2:  t,\  is  a  primitive  task,  p\  is  a  simple  plan  for  t\,  ( P2---Pn )  achieves 
(t2  ■  ■  -  tk)  from  result (O,  p\ ); 

Case  3:  t\  is  a  compound  task,  and  there  is  a  simple  reduction  (n  . . .  rj )  of  t\  in 
O  such  that  P  achieves  (rq  . . .  ■  ■  -  tk)  from  O. 

The  planning  problem  (O,  t,T>)  is  solvable  if  there  is  a  plan  that  solves  it. 


E.  Proof  of  the  Main  Theorem 
Theorem  2  (Soundness  of  A-SHOP). 

Let  O  be  a  state,  V  be  a  collection  of  agentized  methods  and  operators  and  let 
t  be  a  list  of  tasks.  Let  all  the  preconditions  in  the  agentized  methods  and  add 
and  delete- lists  in  the  agentized  operators  are  strongly  safe  wrt.  the  respective 
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variables.  Furthermore  suppose  one  of  the  nondeterminstic  traces  of  A-SHOP 
(O,  t,V)  returns  a  plan  P.  Then  P  solves  the  planning  problem  (O,  t,T>). 

Proof:  We  first  notice  that  steps  7  and  12  always  terminate:  this  follows  from 
Lemma  6  (it  is  exactly  where  we  need  the  assumptions  about  strongly  safeness 
of  the  operators  involved).  All  other  steps  terminate  trivially. 

The  proof  is  by  induction  on  n,  where  n  is  the  number  of  times  A-SHOP  is 
called. 

Base  case  (n  =  1):  In  this  case  A-SHOP  does  not  call  itself  recursively,  so  it 
must  return  at  step  1. 

Thus  t  =  nil  and  P  =  nil,  so  from  Case  1  of  the  definition  of  “achieves” ,  P 
achieves  t  in  O. 

Induction  step:  Let  n  >  1,  and  suppose  that  the  theorem  is  true  for  every 
m  <  n.  There  are  two  cases: 

Case  1.  A-SHOP  returns  P  at  step  5.  Let  t,i?,and  q  be  as  computed  in  steps 
2-4  of  A-SHOP.  Then  R  =  (fif2  •  •  •  U)  for  some  i.  Let  [p±P2  ■  ■  ■ Pj )  be  the 
plan  returned  by  the  recursive  call  to  A-SHOP  ( R,T> )  in  step  5.  From  the 
induction  assumption  it  follows  that  (pip-2  ■  ■  ■  Pj )  achieves  {t\t2  ■  ■  -U)  in  the 
state  result(0,p).  But  t  is  a  primitive  task  and  p  is  a  simple  plan  for  t  in 
O.  Thus  from  Case  2  of  the  definition  of  “achieves,”  the  plan  (pp±P2  ■  ■  -  Pj) 
achieves  the  task  list  t  =  (tt\t2  ■  ■  ■  U)  in  O. 

Case  2.  A-SHOP  returns  P  at  step  8.  Let  t  and  R  be  as  computed  in  step  2  of 
A-SHOP.  Then  R  =  (t\t2  ■  ■  -  U)  for  some  i.  Let  R'  be  the  simple  reduction 
of  fchosen  in  step  7  of  A-SHOP.  We  know  that  R'  =  (r\V2  ■  ■  ■  rj )  for  some  j 
and  P  =  (pip2  ■  ■  ■ Pk )  f°r  some  k.  From  the  induction  assumption  we  know 
that  (pip2  ■  ■  ■ Pk )  achieves  {r-prz  ■  ■  ■  Tjt\t2  ■  ■  ■  U)  in  O.  Thus  from  Case  3  of 
the  definition  of  “achieves,”  P  achieves  t  =  (tt\t2  ■  ■  -  U)  in  O.  3 


Theorem  3  (Completeness  of  A-SHOP). 

Suppose  that  the  planning  problem  (O,  t,X>)  is  solvable,  i.e.  there  exists  a  se¬ 
quence  of  ground  instantiations  of  operators  hi,...,hn  from  V  satisfying  the 
task  list  t.  Then  at  least  one  of  the  nondeterministic  traces  of  A-SHOP(0,  t,  V) 
returns  a  plan. 
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Proof:  As  in  the  last  theorem,  we  notice  that  steps  7  and  12  in  A-SHOP  always 
terminate  (Lemma  6).  All  other  steps  terminate  trivially. 

For  every  plan  P  that  solves  (O,  t,V),  let  P’s  solution  depth  be  the  length 
of  P  plus  the  total  number  of  simple  reductions  needed  to  produce  P  from  t. 
Let  the  minimum  solution  depth  of  (0,t,T>)  be  the  smallest  solution  depth  of 
any  plan  that  solves  it.  The  proof  is  by  induction  on  n.  where  n  is  the  minimum 
solution  depth  of  t. 

Base  case  (n  =  0):  In  this  case,  t  =  nil  and  P  =  nil  ,  so  A-SHOP  returns  P  at 
step  1. 

Induction  step:  Let  n  >  1,  and  suppose  that  the  theorem  is  true  for  every 
m  <  n.  There  are  two  cases: 

Case  1.  t  =  (tit2  ■  ■  ■  tk)  for  some  k,  and  t\  is  primitive.  Then  there  must  be 
at  least  one  simple  plan  p  for  t\  for  which  the  minimum  solution  depth  of 
(result(C,p),  (t2  •  •  •  tk ),  P)  is  n— 1,  for  otherwise  the  minimum  solution  depth 
of  (O,  t,V)  could  not  be  n.  At  step  6,  one  of  the  nondeterministic  traces  of 
A-SHOP  recursively  invokes  A-SHOP(result(C>,p),  (t,2  ■  ■  ■  tk),  V).  From  the 
induction  assumption,  this  recursive  invocation  of  A-SHOP  returns  a  plan 
{p\P2  ■  ■  ■ Pk )•  Thus  at  step  6,  A-SHOP  returns  (pp±p2  ■  ■  ■ Pk )• 

Case  2.  t  =  (t\t2---tk)  for  some  k,  and  t\  is  non-primitive.  Then  there 
must  be  at  least  one  simple  reduction  R  =  •  •  •  O')  f°r  such  that 

the  minimum  solution  depth  of  (O,  {r\r2  ■  ■  ■  . . .  tk),  V)  is  n  —  1,  for  oth¬ 

erwise  the  minimum  solution  depth  for  (O,  t,V)  could  not  be  n.  At  step 
11,  one  of  the  nondeterministic  traces  of  A-SHOP  recursively  invokes  A- 
SHOP(0,  (r i?’2  . . .  Tjt‘2  . . .  tk),  V)-  From  the  induction  assumption,  this  re¬ 
cursive  invocation  of  shop  returns  a  plan  (pip2  ■  ■  ■ Pk )•  Thus  at  step  6,  A- 
SHOP  returns  (p\P2  ■  ■  ■ Pk )•  I 


